I don't like having a lot of extra logic for validating and creating new hook names when this could also be solved by just changing the structure used when saving hooks. We have that ContextConfig is already saved per profile, so instead of saving hooks as a list of hooks, why not instead have it be:

ContextConfig {
    paths: ...,
    hooks: HookConfig {
        conversation_start: { [key: string]: Hook },
        per_prompt: { [key: string]: Hook },
    }
}

This way we could also avoid having to create randomly generated id's for hook names. I feel it's simpler for us and the user to just present an error to the user stating a hook with that name already exists instead of this approach.

ContextConfig {
    paths: ...,
    hooks: HookConfig {
        conversation_start: { [key: string]: Hook },
        per_prompt: { [key: string]: Hook },
    }
}

This won't work either. Hook names have to be unique across conversation_start AND per_prompt, otherwise this is ambiguous: /context hooks rm my_hook. my_hook could be in either of the categories.

This way we could also avoid having to create randomly generated id's for hook names. I feel it's simpler for us and the user to just present an error to the user stating a hook with that name already exists instead of this approach.

It's not random, and I would argue its easier for the user because there is never a failure point for them. Their hook always gets added. Also, there is a lack of any config validation happening that we desperately need, whether right now or later (currently if there is an issue with the JSON then the context manager just doesn't load without any warning to the user).
However, the automatic renaming may be confusing, and maybe this issue is a just a symptom of the structure of the config. Maybe we can resolve this by just changing the schema to not have these separations. Thoughts?

context.json

{
    paths: [ ... ],
    hooks: {
        my_hook : { // the name, which is now unique amongst all hooks in the config file
             // category
             "when": "conversation_start" | "per_prompt", // open to a different name, could be "on" as well
             
              ... normal hook data
        }
        ...
    }
}

and I would argue its easier for the user because there is never a failure point for them. Their hook always gets added. Also, there is a lack of any config validation happening that we desperately need, whether right now or later

Definitely true about handling validation and serialization errors - although, the random naming is still just strange to me because hooks should probably have some more semantic meaning to their name instead of just having the user get away with hook_1, hook_2, hook_3 etc. I'd like to hear others thoughts on this hook naming part before going with this approach.

Maybe we can resolve this by just changing the schema to not have these separations. Thoughts?

I'd prefer this! Saves having to have hook name as a validation check in any validation logic we might have.